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ABSTRACT 



This thesis investigates the problems associated 
with operating a real-time warfare simulation system 
over an ARPANET-based packet switched network. The 
network throughput requirements of the simulation are 
determined from measurements taken over a local area 
network. The performance of the packet switched 
network is analyzed through the use of a switching node 
model, resulting in a graph of application throughput 
as a function of the internal network traffic. The 
throughput requirements are compared to this function, 
and maximum acceptable levels of internal traffic are 
determined. The effects of other aspects of packet 
switching are discussed including traffic dynamics, 
packet routing, and flow control. The results suggest 
that it may be possible to conduct a very restricted 
warfare simulation over this network. A better 
networking solution may be to use dedicated network 
resources instead of packet switching. 
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I. INTRODUCTION 



This thesis is an investigation into a problem of 
applied computer network analysis. The Naval Ocean 
Systems Center (NOSC) has developed and maintained a 
real-time, interactive, warfare simulation known as the 
Interim Battle Group Tactical Trainer (IBGTT). NOSC 
has been able to operate this system in a distributed 
manner over a local area network, but it has never been 
operated over a wide area network. Current planning is 
for this system to be networked using the Defense 
Integrated Secure Network (DISNET), a wide area, packet 
switched network based on the ARPANET architecture. 

This thesis attempts to determine whether this packet 
switched network can be reasonably expected to provide 
all levels of performance required by IBGTT. This 
problem will be approached in three phases. 

First, the network requirements of the IBGTT system 
will be determined. In doing this, the highest 
priority will be given to preserving the user 
characteristics of IBGTT. That is, a user should not 
be able to tell from the operation of the system that 
the simulation is being conducted over a wide area 
network. Any network solution which requires a loss of 
user function will be considered sub-optimal. 

Second, the expected performance of the packet 
switched network will be determined. This will 
primarily involve performing delay and throughput 
analysis on the ARPANET architecture. To achieve some 
quantitative estimates of network performance it is 
necessary to model both the network and the application 
in a manner that makes the problem soluble. The 



assumptions necessary to this model will be discussed 
in det ai 1 . 

Finally, the networking requirements of IBGTT will 
be compared to the predicted performance of DISNET . 
This comparison is complicated, in that it requires a 
consideration of nearly every aspect of the operation 
of a packet switched network. While the complexity of 
these issues make it difficult to provide absolute 
answers, it is hoped that this discussion can at least 
point out what the important issues are. 
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II. APPROACH TO THE PROBLEM 



A. PROBLEM CONSTRAINTS 

1 . Application 

The basic characteristics of the Interim Battle 
Group Tactical Trainer (IBGTT) will be considered 
invariable for the purpose of performing analysis. 

These include both the user characteristics and the 
technical characteristics. In fact, in actual 
operation it may be possible to limit some of the user 
characteristics in order to make networking feasible, 
but this will not be considered a very desirable 
solution. The primary concern of this thesis is to 
determine what level of performance is required to 
operate the IBGTT system over the network with all of 
its user characteristics intact. 

2 . Interconnecting Network 

The network performance analysis will only 
consider the use of the Defense Integrated Security 
Network (DISNET) as the interconnecting network, as 
this is the only system that is currently approved by 
the Department of Defense (DOD) for secure computer 
communications. Since DISNET is in the process of 
being implemented, this analysis will be based on 
information about existing networks which use the same 
architecture, ARPANET and MILNET . No other types of 
packet switched networks (such as CCITT) will be 
analyzed . 

3 . Application-Network Interfaces 

The interface between the application and the 
existing packet switched network will not be considered 
to be constrained to any currently existing 



configurations. For the purpose of this analysis, this 
interface will be assumed to be configured such that 
maximum data throughput is obtained. This includes 
both the software interface between IBGTT and the 
network protocols, and the physical connections between 
the application computers (hosts) and the network 
packet switches (nodes). 

In the case of both software and hardware 
interfaces, it is reasonable to assume an optimum 
configuration for two reasons. First, neither of these 
interfaces is well defined. In the case of the 
software, meaningful documentation is scarce. In the 
case of the hardware, the actual interface 
specification seems to be constantly changing. Second, 
these interfaces are the easiest and cheapest 
components of the system to change. Considering the 
software, the data output driver can be changed without 
modifying the application software itself. Similarly, 
if the initial hardware used to connect is found to be 
inadequate it can be replaced with higher capacity 
hardware for relatively low cost. 

B. ANALYSIS PROCEDURES 

Two different aspects of the proposed system will 
be analyzed in this thesis. First, the throughput 
requirements of the warfare simulation will be 
determined. Second, the expected throughput of the 
packet switched network will be projected through the 
use of a network model. After this is done, the 
required throughput will be compared to the expected 
network performance. 

1 . Application Throughput Requirements 

The IBGTT system is currently operating in the 
distributed mode over an ETHERNET local area network at 



NOSC . Using DECNET , measurements of the amount of data 
being sent between computers during the simulation can 
be made. These measurements have been obtained from 
NOSC for different operating conditions, resulting in 
some reliable values for the required data throughput 
of the system. 

However, before this data can be transmitted 
over a packet switched network it has to be packaged by 
a series of network protocols. Each of these protocols 
adds some information to the data in the form of packet 
headers and trailers. This protocol overhead will be 
enumerated and added to the required data throughput to 
obtain measures of the total throughput required by the 
IBGTT system for normal operation. For a network to 
permit unconstrained operation of the system it must be 
capable of handling this throughput requirement. 

2 . Network Performance Analysis 

Expected network performance will be analyzed 
through the use of a switching node model. Using this 
model and knowing much about the behavior of the 
application process, it is possible to derive an 
expression which relates the waiting time of an 
application output packet to the dynamics of the 
network’s internal traffic. If certain assumptions are 
made about the internal traffic, this expression can be 
explicitly solved. The waiting time equation is the 
starting point for the remaining analytical procedures. 

It is possible to obtain an expression from the 
waiting time equation which relates traffic stability 
at a node to the arrival rates of the internal network 
traffic and the external application traffic. Using 
this stability equation, a critical rate can be defined 
in terms of these arrival rates. From the critical 
rate expression, an equation which defines the maximum 



(critical) application arrival rate as a function of 
the internal traffic is obtained. From this, a curve 
showing application throughput as a function of 
internal network load will be generated. 

This relationship between application 
throughput and network load will be used as the basis 
for determining under what conditions of network 
operation will DISNET be capable of meeting the 
networking needs of IBGTT. 



III. INTERIM BATTLE GROUP TACTICAL TRAINER 



A. USER CHARACTERISTICS 

For the purpose of this thesis, it is not necessary 
for a complete description of the user characteristics 
of the application program to be included. Therefore, 
only those features which have a direct impact on the 
ability to operate over a packet-switched network will 
be discussed below. Additional information on the 
operating features of the program can be found in the 
system’s user guides [1], [2]. 

1 . Real-Time Simulation 

Possibly the most important feature of the 
Interim Battle Group Tactical Trainer (IBGTT) from the 
perspective of the user is the fact that the game runs 
in real-time. This means that the user has the same 
amount of time to act or react to tactical situations 
as he would in a real conflict. For example, if 
approaching aircraft were expected to be within the 
user’s weapons range in two minutes then the user would 
only have two minutes of actual time to take action. 

It is this feature of real-time operation which makes 
IBGTT an effective training device. 

2 . Different Operating Speeds 

A second important user feature is the 
capability to run the game faster than real-time. 

While this may appear to contradict the real-time 
feature, the two actually work together to produce an 
effective training environment. 

During a large-scale battle problem a great 
deal of time may be spent searching for the opponent’s 
forces. If the problem were run at real-time the 
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participants might spend many hours waiting for the 
enemy to be detected. By allowing the game to run 
faster than real-time it is possible to shorten the 
detection phase of the problem. Once the actual 
conflict begins the warfare simulation can be run at 
real-time from that point on. During tactical training 
the simulation would not normally be operated at a 
speed slower than real-time, for the reasons already 
stated . 

3 . Opportunity for Large Scenarios 

In order for the training to be realistic, the 
magnitude of the battle problems constructed should not 
be drastically scaled down from those anticipated in 
real life. For this reason IBGTT is capable of 
including a large number of combatant units in its 
scenarios, as many as 1500 objects. 

4 . Multiple Users with Different Perspectives 

The IBGTT system is designed to simultaneously 

support each of the separate warfare commanders under 
the Navy’s CWC concept. This means that while one user 
has access to all the information necessary to perform 
the functions of the anti-air warfare commander ( AAWC ) , 
the user at the next station might need the information 
necessary to act as the anti-submarine warfare 
commander ( ASWC ) . Thus, IBGTT must be able to present 
and maintain different status boards and displays to 
each of the different user stations. 

Another important capability of the system is 
that of supporting one group of users as the Blue 
forces and another group as the Orange forces. A third 
person or group may need to be supported at a Control 
station, with access to virtually all the information 
so they can monitor and direct the simulation. 



B. TECHNICAL CHARACTERISTICS 

1 . Distributed Architecture 

The IBGTT system has been developed so that it 
can be operated in either of two ways: merged or 
distributed. In the merged form the system software is 
executed on a single, stand-alone computer. Thus, all 
the system functions described below are performed on 
that computer. This is how the system is currently 
operated at the Naval Postgraduate School (NPS). 

In the distributed form of IBGTT the system 
functions are divided into two groups: user interface 
functions, and simulation execution. The user 
interface function is performed by one or more computer 
systems called Remote Site Modules ( RSM ) . The 
simulation execution is performed by a single computer 
system called the Computer Support Facility (CSF). The 
IBGTT system is currently operated in the distributed 
form at NOSC using an ETHERNET to connect the CSF and 
RSM computer systems*. 

a. Remote Site Module 

System users interact with IBGTT through 
the RSM. A simple block diagram of an RSM is shown in 
Figure 1 . As shown, an RSM includes a digital 
computer, 2 color graphics controllers, 4 user stations 
(2 per graphics controller), and remote communications 
equipment. This description of an RSM is based on the 
system configurations currently in use at NOSC [3]. It 
is quite possible that future RSMs at other sites will 
be physically different from this, but they should 
still be functionally equivalent to this description. 

*The previous designations for these systems were 
User Support System (USS) for the RSM and Simulation 
Support System ( SSS ) for the CSF . Some references 
cited in this thesis use the previous designations. 
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Figure 1* 



Remote Site Module System Diagram 
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The RSM functions by accepting orders from 
the users and transmitting them to the CSF for 
processing. After CSF processing, the RSM receives the 
updated simulation status from the CSF and uses it to 
update its local copy of the simulation database. The 
RSM uses the information in this database to generate 
and update the different tactical displays at the user 
stations . 



It is possible for the IBGTT system to be 
configured with more than one RSM for large battle 
problems. For example, one RSM might be used by the 
Blue forces and the other by the Orange forces. In a 
case such as this, each RSM would only be responsible 
for maintaining the tactical displays appropriate to 
its users. However, an RSM responsible for maintaining 
the Control station would need to maintain nearly all 
the tactical information in its database. Regardless 
of how many RSMs are configured there would only be one 
CSF in the system. 

b. Computer Support Facility 

The CSF is that part of the IBGTT system 
that actually executes the warfare simulation. A 
simple block diagram of a CSF is shown in Figure 2. As 
shown, the major components of a CSF include a digital 
computer, disk storage, magnetic tape drive, line 
printers, video display terminals, and remote 
communicat ions equipment. As before, this describes a 
CSF as currently configured at NOSC [4] . 

The CSF receives user commands from the RSM 
and processes them by calculating the updated status of 
the simulation. The simulation status is updated every 
simulation minute, called a game cycle. These game 
cycle updates are performed whether or not any commands 
are issued by users [1:1-1 -2]. When the simulation is 
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Figure 2. Computer Support Facility System Diagram 
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operating faster than real-time the CSF will perform 
two or more of these game cycles for every minute of 
actual time. The updated simulation status is 
maintained in the CSF database, which is the primary 
database for the simulation. The appropriate changes 
to the database are transmitted to the RSM for display 
processing and local database updating. 

2 . Software Design 

a. Database Concurrency 

As described above, the distributed IBGTT 
system performs the actual simulation execution on a 
single computer, the CSF, regardless of the size of the 
battle problem or the number of users participating. 
This means that the system should appear to the user to 
be a distributed processor, but that it is actually a 
centralized processing system with remote display 
processing. The distinction is very important, as 
explained below. 

The IBGTT system creates and maintains a 
simulation database, called the blackboard, in the form 
of data tables [5:4-5]. Each object in the problem, 
such as an aircraft or a ship, has a separate table 
maintained for it in the CSF ’ s blackboard. This table 
contains all the information on that object available 
to the simulation. An example of an object data table 
is shown in Figure 5. As shown, the table includes 
both fixed information (such as type of unit) and 
variable information (such as course, speed, latitude, 
longitude). A copy of each table can reside locally in 
the RSM database, but it is only a copy--the true 
status of the object is determined by the table in the 
CSF database. 

When a system user enters commands at the 
RSM (such as changing the course of a ship) nothing is 
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TABLE: 



ONN 



"Own Force 



DESCRIPTION: "Contains own force 

reported position/ 
status/ etc.." 

FORMAT 



Field 


Type 


Word 


P o s 


S i 2 e 


Range 


UNIT 


I 


1 


0 


1 6 


0-1600 


TYPE 


I 


1 1 


9 


4 


0-15 


STATUS 


I 


1 1 


1 3 


4 


0-15 


MISSION 


I 


1 1 


17 


S 


0-3 1 


LATITUDE 


F 


2 


0 


word 


-90 t o + 9 < 


LONG I TUDE 


F 


3 


0 


word 


-PI t o+P 


COURSE 


I 


4 


9 


9 


0-359 


SPEED 


I 


8 


1 0 


1 2 


0-4095 


ALTITUDE 


I 


4 


20 


1 1 


0-2047 


DEPTH 


I 


4 


20 


1 1 


0-2047 



Figure 3. Example of an Object Data Table 
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done directly to the tables held in RSM memory. The 
commands are transmitted to the CSF and processed. 

After processing, the tables held in the CSF are 
changed to reflect the current status of the 
simulation. The table changes are then transmitted 
back to the RSM so that they can be displayed and the 
local database updated [5:18-20]. 

The apparent advantage of this software 
design is that database concurrency is maintained by 
only allowing table changes to be made in the CSF. The 
disadvantage is that a very large amount of data is 
frequently being transmitted from the CSF to the RSM. 
The CSF will update the status of the simulation every 
game cycle whether or not the users have entered any 
new commands. This results in frequent transmissions 
of new table changes to the RSM because the objects 
which are in motion (such as ships and aircraft) will 
have some of their table fields constantly changing, 
b. Data Extraction 

Anticipating the need to reduce the 
quantity of data transmitted from the CSF to the RSM, 
NOSC has developed a data extractor program which will 
act to filter the data before it is sent to the network 
[5:17]. The extractor works by testing the output 
buffer before it puts the most recent update onto the 
output queue. If the output buffer is nearly full 
(currently the threshold is set at 95%) then the 
extractor ' program will automatically begin to 
prioritize the data before it goes on the queue. High 
priority (data must be transmitted) will be given to 
any data required by an active user display. Data that 
is not currently being viewed by a user is given low 
priority and may not be sent at all. 
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While the extractor program may be 
successful in reducing the amount of data sent from the 
CSF to the RSM, it does so at the cost of a loss of 
user function. If the game were to operate under this 
system for many game cycles, then the problem of an out 
of date database at the RSM occurs. Those parts of the 
database needed to support the active user displays are 
up to date with the CSF, but those parts relating to 
displays which have not been viewed for many game 
cycles may contain information which is completely 
incorrect (such as listing units which have been 
destroyed). This problem will impact on the user when 
a new display is activated: the information in the new 

display will not be current until the next machine 
update is completed. Since the computer processing 
involved in IBGTT is supposed to be transparent to the 
user, this will create distracting and potentially 
confusing conditions. 

For these reasons use of the extractor 
program will be considered a sub-optimal, compromise 
solution to the networking problem. The requirements 
analysis in this thesis will be performed toward the 
goal of maintaining a completely up to date RSM 
database . 

C. NETWORK OPERATION OF IBGTT 

1 . Local Area Network Operation 

The IBGTT system has been in operation over a 
local area network (LAN) at NOSC for quite a while. 

The NOSC LAN consists of an ETHERNET which is 
interfaced by the VAX computers through the use of 
DECNET . A diagram of the LAN is shown in Figure 4. 
While the system has been operated successfully over an 
ETHERNET, that does not mean that the transition to the 



25 



ETHERNET 




Figure 4. IBGTT Local Area Network at NOSC 
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proposed packet switched network will be easy. The 
ETHERNET LAN has a very high capacity, rated on the 
order of 10 Mbps. The possible capacity of an ARPANET- 
based packet switched network is less than this by more 
than two orders of magnitude. Thus, changing from an 
ETHERNET to packet switching involves more than a 
simple change in software and wiring. 

2 . Proposed Wide Area Network 

The Joint Directors of Laboratories ( JDL ) , a 
DOD agency, has directed that IBGTT be used to 
implement a wide area warfare simulation network, 
called Simulation Network or SIMNET [6:56-59]. 
Initially, there are to be four hosts on SIMNET, two 
located on the east coast and two on the west coast. 
These hosts are listed below in Table I. 



INITIAL 

Host Command 


TABLE I . 

, HOSTS ON 

Location 


SIMNET 


Computer 


Naval Postgraduate 
School (NPS) 


Monterey , 


CA 


DEC VAX 1 1 /780 


USA Communications 
and Electronics 
Command (CECOM) 


FT Monmouth, NJ 


DEC MicroVAX II 


USAF Rome Air 
Development 
Center ( RADC ) 


Rome , NY 




DEC MicroVAX II 


Naval Ocean Systems 
Center ( NOSC ) 


San Diego 


, CA 


ETHERNET LAN 
connection made 
to a VAX 1 1 / 780 



A diagram of SIMNET is shown in Figure 5. As 
shown, the actual topology of the interconnecting 
network has not been defined. The current plan for 
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Figure 5. Block Diagram of the Proposed Simulation Network 
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implementing SIMNET is that it will be a logical subnet 
on the Defense Integrated Secure Network (DISNET). 
DISNET, a new packet switched network based on the 
ARPANET model, will be described in detail in the next 
section. It is important to understand that DISNET 
will be providing network services to numerous systems 
and customers other than SIMNET. Thus, a key question 
for this thesis is whether or not DISNET can provide 
the network performance required by SIMNET while 
providing services to the rest of its customers. 
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IV. INTERCONNECTING NETWORK 



A. DEFENSE INTEGRATED SECURE NETWORK 

1 . Network Security 

The Defense Integrated Secure Network (DISNET) 
is a wide area, packet switched network which is 
designed to meet the security needs of the Department 
of Defense. DISNET is a component of the Defense Data 
Network (DDN), a system which also includes the MILNET 
(Military Network). 

Both DISNET and MILNET are based on the ARPANET 
(Advanced Research Projects Agency Network) 
architecture. However, DISNET will be physically 
separate from ARPANET and MILNET--no gateways will 
exist between DISNET and any other network for years. 
This physical separation, along with physical security 
at each computer installation, will permit DISNET 
customers to transmit classified information over the 
network. Classified data transfers are not permitted 
over the unclassified packet switched networks ARPANET 
and MILNET. The eventual goal of DDN is to provide 
gateways between DISNET and MILNET once special 
encryption hardware becomes available [7:16-19]. 

2 . Use of the ARPANET Model 

Because the DISNET design follows the ARPANET 
design very closely, both in software and hardware, 
this thesis will make extensive use of the ARPANET 
literature in its discussion of the DISNET 
architecture. In fact, the development of DISNET is so 
recent that there is virtually no technical literature 
available on it. 
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However, the relationship between performance 
measurements made on the ARPANET and the expected 
performance of DISNET is less clear. In 1984 the 
original ARPANET was divided into two networks, ARPANET 
and MILNET . ARPANET is now a research oriented network 
which is heavily used to transfer data among a number 
of interconnected networks. MILNET is now used as the 
primary computer network for unclassified operational 
military use. It is possible that as customers connect 
to DISNET over the next few years its traffic 
measurements will eventually resemble those currently 
found on MILNET. For this reason, MILNET measurements 
will be used as the basis for network performance 
analysis in this thesis. It is hoped that the results 
will be a good predictor of eventual conditions on 
DISNET . 

B. NETWORK ARCHITECTURE 
1 . Packet Switching 

The ARPANET architecture is designed to support 
computer communications through the use of packet 
switching. In a packet switching network information 
is transferred between computers in the form of 
discrete blocks of fixed maximum length, called 
packets. The network consists of two major components: 
packet switches (called nodes) and connecting trunk 
lines. The packet switches are minicomputers which are 
specially designed to perform this task. On ARPANET 
these packet switches are known as Interface Message 
Processors ( IMPs ) . For trunk lines, ARPANET uses 
leased phone lines which typically have 50 Kbps 
capacity, though there are some lines with other 
capacities (9.6 Kbps and 56 Kbps). The computers which 
are physically connected to the network for the purpose 
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of using the network’s services are called hosts. A 
diagram of the ARPANET model is shown in Figure 6. 

A design requirement of the ARPANET is that 
there must be at least two possible paths between any 
two nodes. These multiple paths allow the network to 
send a computer’s packets over the best available path, 
normally the path with the least delay. Often the 
information being sent between two hosts, such as a 
program or document file, consists of more than one 
packet . In these cases the network may send the 
separate packets over different paths to minimize 
network congestion on any one path. This is possible 
because each packet contains the destination address, 
enabling the network to treat them as independent 
units . 

2 . Interface Message Processors 

Most of the critical functions of the ARPANET 
are performed at the IMPs , including message 
disassembly, reassembly, and message and packet 
queuing. As stated above, a packet on the ARPANET can 
not exceed a fixed length limit. However, it is 
possible for a host to transmit a message to the 
network which is longer than the maximum packet length. 
It is the responsibility of the IMP to which the host 
is connected to disassemble the message into several 
packets. The IMP which performs this function is 
referred to as the source node. The maximum number of 
packets which can be generated by a single message is 
eight, creating a limit on the maximum length of a host 
message . 

The reverse of this process is message 
reassembly, which is performed by the IMP directly 
connected to the destination host. This IMP is 
referred to as the destination node. As stated above, 
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Figure 6. ARPANET Model of a Packet Switching Network 
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it is possible for the component packets of a single 
message to traverse different paths on their way to the 
destination node. Thus, these packets may arrive out 
of order. It is the responsibility of the destination 
node to collect the separate packets and to use them to 
reconstruct the original message. This message is then 
delivered to the destination host. Message disassembly 
and reassembly should be transparent to the host 
computers . 

It is possible for a host computer to send 
messages to an IMP even if the IMP is not able to 
disassemble and transmit them immediately. The IMP 
will simply buffer these messages in an input queue. 
Similarly, the packets sent from one IMP to the next 
may also be buffered in input queues. Message 
disassembly and queuing is depicted in Figure 7, as 
described below. 

As shown, the host has transmitted five 
messages to the IMP. The fifth message (M5) is in 
transit to the IMP. The third and fourth messages (M3 
and M4 ) are waiting in the IMP’S input queue. The 
first and second messages have already been 
disassembled into four packets each, as follows: 

Ml -> PI a , Plb, Pic, Pld 

M2 -> P2a , P2b , P2c , P2d 
The source node has routed half of these packets 
through one adjacent IMP and half through the other. 
Some of the packets are in transit from the source node 
to the next IMP, some are waiting in input queues, and 
some are in transit from the second IMPs to the 
following IMPs. Though reassembly at the destination 
node is not shown, it is clearly possible for these 
packets to arrive out of sequence. Thus, some packets 
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Figure 7. Packet Switching by ARPANET IMPs 
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may have to be stored at the destination node while 
awaiting the preceding packets. 

3 . Host Connections to the Network 

On ARPANET the hosts are often located in close 
proximity (2000 feet or less) to the IMP which connects 
them to the network. This proximity allows the host to 
use a high capacity communications link for this 
connection. However, at least initially there will not 
be enough IMPs on the DISNET for each of its hosts to 
have one located in close proximity. For this reason 
the SIMNET hosts will not be assumed to use high 
capacity links for their host-IMP connections. This 
thesis will assume that trunk lines of 50 Kbps are used 
to connect the SIMNET hosts to DISNET IMPs. 

C. NETWORK PROTOCOLS 

1 . Pr inciples 

Large, highly capable computer networks such as 
ARPANET are very complex. To make this complexity 
manageable, the network is designed as a series of 
layers with each layer performing specific functions. 
Each network layer is associated with a protocol, which 
is the set of algorithms designed to perform the 
function of the layer. By breaking the network 
functions into a hierarchy of protocol layers it is 
possible for the user to establish communication with a 
distant host, a high level function, without being 
concerned about low level functions such as the 
signalling method used over the trunk lines. 

Layering simplifies the network problem by 
allowing each layer to view the set of lower layers as 
simply providing the network services it needs to use. 
How a specific protocol performs the functions of its 
layer is of no interest to the layers above. Thus, 
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only the interfaces between layers are of importance, 
not the internals. This is the principle of 
information hiding, and its use in network design 
permits changes to be made to individual protocols 
without affecting the overall functioning of the 
network. An excellent discussion of protocol layering 
is given by Zimmermann [8] . 

The most frequently discussed set of layered 
protocols is the Open Systems Interconnection (OSI) 
reference model, which has been proposed by the 
International Organization for Standardization (ISO) 
[8], [9:15-21]. However, the ARPANET design predates 

the OSI model by almost ten years and does not strictly 
conform to it. For this reason, the specific ARPANET 
protocols will be discussed below, rather than the more 
commonly reviewed OSI protocols. 

2 . Network Application 

The highest layer in the hierarchy of network 
functions is the application program which is using the 
network services. In this case the application is 
IBGTT software, which can be either the CSF program or 
the RSM. This thesis will concentrate on the 
performance of the network from, the perspective of the 
CSF, but the principles are the same from either 
perspective . 

The application program has to send both data 
and network information to the next layer in the 
hierarchy, the Transmission Control Protocol (TCP). 

The way in which information is passed from IBGTT to 
TCP is determined by the TCP interface. However, the 
IBGTT programs do have some control over how data is 
transmitted, in that they can specify an end of data 
block (called a Push) to TCP. If no Push is sent then 
TCP will be able to package the data into maximum 
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length data blocks, which is the most efficient means 
of transmitting a large amount of data. Throughout 
this thesis IBGTT will be assumed to send data blocks 
of the maximum possible length to TCP until all the 
data for that game cycle has been sent. Only after all 
the game cycle data has been sent will a Push be sent, 
so that only one partial TCP frame may be generated per 
game cycle. 

3 . Transmission Control Protocol 

TCP is primarily responsible for maintaining a 
reliable host-to-host connection for the purpose of 
transferring data. The TCP functions which will be 
discussed in this thesis include establishing 
connections, transferring data, and ensuring adequate 
flow control. A diagram of the TCP format is shown in 
Figure 8. A complete description of TCP can be found 
in the official protocol specification [10]. 

Before any data transfer can occur a connection 
has to be made between the two hosts. TCP does this 
through the use of a three-way handshake. Port numbers 
are assigned to each end of the connection to identify 
the logical channels to which the data should be sent 
at each host. These port numbers are included in every 
TCP header, as seen in Figure 8. TCP is also 
responsible for breaking the connection once the 
application is finished. 

The options section of the TCP header is 
normally only used during connection set-up. Once data 
transfer begins the TCP headers usually consist of the 
first 20 bytes indicated in Figure 8. One option used 
during connection set-up is that of determining the 
maximum data segment length which will be used during 
the connection. As discussed above, this value will be 
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Figure 8. Transmission Control Protocol Format 
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24 a more BYTES 



assumed to be the maximum data segment available to the 
TCP protocol . 

A large portion of the TCP header is used to 
perform flow control between the hosts. TCP uses 
windows and acknowledgements to maintain flow control, 
but it does this by counting bytes instead of messages. 
Each byte of data sent from a host is counted and given 
a sequence number. The sequence number field contains 
the number of the first data byte in the segment. 
Windows and acknowledgements are returned by the 
receiving host. The acknowledgement field contains the 
next expected sequence number, while the window 
comprises the number of additional bytes that the 
receiving host is prepared to accept. Flow control 
will be discussed again later in the thesis. 

Once TCP has prepared the complete frame it is 
sent to the next protocol in the hierarchy, which is 
the Internet Protocol (IP). TCP sends some information 
to IP outside of this frame which IP uses to construct 
its own header. This information includes the source 
address, destination address, protocol used (i.e., 

TCP), and the length of the complete TCP frame. 

4 . Internet Protocol 

The Internet Protocol (IP) is designed to 
provide those functions necessary to deliver a package 
of bits, called a datagram, from one host to another. 

IP has a number of features which enable the protocol 
to send datagrams across connected networks. These 
features allow the IP datagrams to be fragmented into 
smaller datagram fragments if the intervening networks 
do not permit packets as large as the intact datagram 
to cross. These fragments can then be reassembled at 
their destination using information contained in the IP 
header. Since it is expected that SIMNET will operate 
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over a single network, DISNET, these features will not 
be significant for this thesis. 

A diagram of the IP format can be seen in 
Figure 9. As shown, IP treats the entire TCP frame as 
if it were data by simply attaching it to the end of 
the IP header . The only items of information from TCP 
that IP uses directly are those that were passed 
outside of the header: addresses, protocol type, and 
frame length. Besides fragmentation, the major 
function of IP is simply in providing addresses to the 
datagrams. Note that the IP header does not contain 
fields for sequencing or flow control. To this 
protocol each datagram is just an independent unit with 
a destination address. 

The options field of the IP header is not used 
in most datagrams. Thus, the typical IP datagram has a 
20 byte header. The field called time (usually "time 
to live") is set at some time value when the header is 
created. As the datagram passes through the network 
this field is reduced each time the IP header is 
processed. If the field reaches zero, then the 
datagram is discarded. This timeout mechanism is 
designed to keep undelivered datagrams from creating 
congestion on the network. More information on the 
features of IP can be found in the official protocol 
specification [11]. 

When the IP frame has been completed it is 
passed to a network access protocol for further 
packaging. The product of the network access protocol 
will be an ARPANET message which can be sent from the 
host to a network IMP. 

5 . Network Access Protocols 

Network access protocols establish the 
interface between a host computer and the IMP to which 
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14 a more BYTES 



it is connected. A network access protocol is 
responsible for providing the reliable transfer of 
data, in the form of IP datagrams, between hosts and 
IMPs. In the ARPANET architecture there are two 
different network access protocols in use: the BBN 1822 
protocol and the DDN X.25 protocol. 

The BBN 1822 protocol is the original network 
access protocol on the ARPANET [12:154-157]. While 
1822 is still in widespread use on the network, it is 
being slowly phased out in favor of the DDN X.25 
protocol. It is expected that all hosts on SIMNET will 
interface with DISNET through the use of DDN X.25. For 
this reason the BBN 1822 protocol will not be discussed 
further in this thesis. 

The DDN X.25 is a very highly specified subset 

of the CCITT X.25 specification [15]. The official DDN 

X.25 specification states, 

Thus in several areas where X.25 allows a choice, a 
single choice appropriate for DDN is specified; in 
areas which X.25 leaves unspecified, addressing in 
particular, conventions are specified that are 
consistent with the overall architecture [of] DDN . 

. . . [13:2] 

For this reason the DDN X.25 is quite different from 
the more general CCITT specification. A diagram of the 
DDN X.25 format is shown in Figure 10. 

As shown, X.25 treats the IP frame as data, 
inserting it between its header and trailer. The short 
(5 bytes) X.25 header is primarily concerned with 
addressing and identif ication . Note that there are no 
fields dedicated to sequencing and flow control. As 
with IP, these higher level functions are assumed by 
X.25 to be handled by TCP. The requirement that X.25 
provide reliability is met through the use of a 1 6 bit 
frame check sequence as a trailer. This sequence 
provides an error check over the entire X.25 frame. 
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Figure 10. DDK X. 25 Protocol Format 
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A complete DDN X.25 frame is called an ARPANET 
message. When a message is complete the X.25 protocol 
transfers it from the host to the connected IMP where 
it will be further processed before being sent out on 
the network. In a similar fashion, the X.25 protocol 
is also used by the IMP to transfer received messages 
to the destination host. 

Thus, three levels of protocol packaging are 
performed on a segment of application data before it is 
sent from the host to the network. A graphical 
overview of this process is shown in Figure 1 1 . 

6 . IMP-IMP Protocol 

So far , each protocol has added information to 
the data package simply by attaching a header (and a 
trailer for X.25) to the package it receives from the 
higher level protocol . However , the transition from 
the X.25 protocol to the next protocol level is more 
complicated than this. This is because an X.25 ARPANET 
message which is longer than the maximum IMP-IMP packet 
length must be disassembled into smaller packets before 
it can be sent onto the network, as discussed earlier. 
Each of these smaller packets is then given its own 
IMP-IMP protocol header before it is transmitted. 

A diagram of the message disassembly process is 
shown in Figure 12. As shown, only the IP frame 
portion of the message is disassembled and transmitted 
onto the network. The X.25 header and trailer are not 
sent beyond the source IMP. The information in the 
X.25 header is used to construct the IMP-IMP headers 
which are attached to the disassembled packets, a 
process called protocol conversion. When these packets 
reach the destination IMP the X.25 header is 
reconstructed from the information in the IMP-IMP 
headers. Similarly, the X.25 checksum trailer is only 
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Figure 11. Data Packaging in an ARPANET Message 
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Figure 12. Disassembly of an ARPANET Message 
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used to determine if any errors occurred during the 
transmission from the host to the IMP. Once checked, 
the trailer is discarded by the IMP. When the X.25 
message is reconstructed at the destination IMP the 
checksum trailer is recomputed. 

Note that the entire IP frame is treated as 
data by the disassembly process. The information 
contained in the TCP and IP headers is not used by the 
IMP-IMP protocol. Each resulting data packet is given 
its own IMP-IMP header, which adds an additional 16 
bytes to create an IMP-IMP frame. This header has all 
the address and routing information needed to transmit 
the packet to the destination. Separately addressing 
each frame allows them to be routed over independent 
paths, as discussed earlier. The IMP-IMP header is 
described in detail by Tanenbaum [9:226-231]. 

The IMP-IMP frames shown at the bottom of 
Figure 12 each represent a complete unit of information 
needed by the destination. However, before a frame can 
be reliably sent over a trunk line it needs to be 
further framed with a hardware generated header and 
trailer [9:165-167]. The format of this final IMP-IMP 
packet is shown in Figure 13. 

As shown, the hardware generated header is only 
three bytes long. It consists of the three control 
characters SYN , DLE , and STX . These characters signal 
the receiving IMP that an IMP-IMP frame is arriving. 
These bytes are followed by the IMP-IMP header and the 
data packet. The start of the six byte hardware 
generated trailer is signalled by the control 
characters DLE and ETX. These are followed by a 24 bit 
checksum which is computed over the entire frame. The 
packet ends with the SYN control character. 
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7 . Summary 

As described above, the IBGTT data has to pass 
through three levels of network protocols before it can 
be sent from the host to a network IMP as an ARPANET 
message. The message is then disassembled and 
repackaged using the IMP-IMP protocol . These protocols 
are summarized below in Table II. 





TABLE II. 






SUMMARY OF ARPANET 


PROTOCOLS 


Protocol 




Function 


Transmiss 

Protocol 


ion Control 
(TCP) 


Provide a reliable 
host-host connection 


Internet 


Protocol (IP) 


Datagram transmission 


DDN X . 25 


Protocol 


Provide host-network 
interface 


IMP-IMP Protocol 


Reliable transfer of 
packets through the 
network 



The IMP-IMP packets are delivered to the 
destination node, where they are used to reconstruct 
the original message. This message is delivered to the 
destination host, where it is unpackaged from the 
successive protocols. Finally, the original data 
segment is delivered to the appropriate host process. 
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V. REQUIRED APPLICATION THROUGHPUT 



A. PROCEDURE 

1 . Data Collection 

As described previously, IBGTT is currently 
operated in the distributed mode through the use of an 
ETHERNET LAN at NOSC . The DEC computers used for this 
system can monitor the ETHERNET traffic via DECNET , the 
standard DEC network software. Using these tools, 
measurements of the amount of IBGTT data transferred 
between the CSE and the RSMs were obtained by personnel 
at NOSC. 

The DECNET measurements are all made with 
respect to the CSF (called the executor node by 
DECNET). Thus, the bytes sent from the CSF to an RSM 
(remote node) are listed under the RSM as "bytes sent". 
None of the data listed under the CSF reports the data 
sent to RSMs . Thus , to determine the total CSF to RSM 
traffic for a game with more than one RSM the bytes 
sent to each RSM must be added. The terms CSFout and 
RSMin will be used to describe this CSF to RSM traffic. 
Using this notation, CSF output can be expressed for a 
game with two RSMs by the following formula: 

CSFout = RSMIin + RSM2in (5.1 ) 

This thesis will be almost entirely concerned 
with the CSF to RSM traffic. The DECNET measurements 
show that the RSM to CSF traffic is negligible in 
comparison, normally less than one percent. Thus, CSF 
throughput and application throughput are considered 
synonymous . 
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2 . Protocol Overhead 

The DECNET measurements are for bytes of 
application data sent. Before these measurements can 
be applied to an ARPANET based network the overhead for 
each protocol layer must be added. The starting point 
for determining total overhead is the network limit on 
the maximum IP frame, which is 1007 bytes. As 
discussed previously, the length of the data segment 
inside this IP frame equals the frame length minus the 
size of the IP and TCP headers (see Figure 11 in 
Chapter IV). For each of these headers the most 
commonly used length is 20 bytes. Thus, the maximum 
data segment can be computed as follows [14]: 

max data segment = 1007 - 20 - 20 = 967 bytes ( 5.2 ) 

Since IBGTT is assumed to always use maximum length 
data segments, protocol overhead will be calculated 
using 967 bytes for the data segment length. 

After the IP frame is formed it is further 
packaged by DDN X.25 protocol. This protocol adds a 5 
byte header and a 2 byte trailer for a total of 7 bytes 
of overhead. The total maximum length X.25 ARPANET 
message is therefore 1014 bytes long. This message 
consists of 967 bytes of data and 47 bytes of overhead. 
Application data efficiency can be expressed as 
f ol lows : 



eff = 100% * (967)/(1014) = 95-365 % 



( 5.3 ) 



This ratio is used to convert the data 
throughputs measured by DECNET into measurements of the 
total throughput which the CSF must transfer across the 
network to the RSM. The conversion equation follows: 
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throughput = data / 0.95365 



( 5.4 ) 



From here on the measurements discussed in this thesis 
will be for total throughput (data plus overhead). 
Listings of the original DECNET data measurements are 
provided in the Appendices. 

3 - Simulation Operating Speed 

As discussed previously, an important feature 
of IBGTT is the ability to run the simulation at faster 
than real-time. Thus, the speed at which a simulation 
is operating is an important factor when considering 
the resultant throughput. For example, a game being 
played at 2:1 speed (two game cycles for every actual 
minute of time) should require twice the throughput as 
the same game being played at 1:1 speed. This is 
because the CSF has to transfer two complete simulation 
updates to the RSM every minute instead of one. 

Any throughput measurements which are obtained 
at operating speeds faster than 1 :1 will be normalized 
to the equivalent 1 :1 throughput. This 1 :1 throughput 
represents the minimum throughput required by that set 
of game conditions. While these measurements will be 
the lowest possible for that simulation, they do not 
necessarily represent a desirable operating condition. 
For reasons discussed earlier, it may not be desirable 
to operate at 1:1 speed during some phases of the 
simulation. For this reason, any measurements taken at 
speeds higher than 1:1 will also be evaluated at the 
higher speed. 
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B. SIMULATION MEASUREMENTS 



1 . Game 1 

The first set of measurements to be considered 
were taken during a simulation conducted at NOSC on 
June 5, 1986. This simulation will be referred to as 

"game 1". Game 1 was conducted using two RSMs (RSM1 
and RSM2 ) . The simulation was operating at 2:1 speed 
throughout the measuring period. Data throughput 
measurements for each RSM were used to determine the 
required CSF throughput, as described earlier. These 
throughput requirements are listed below in Table III. 
Note that CSFout at speed = 2:1 reflects the actual 
simulation conditions, while the data for speed = 1:1 
represents the normalized values. The DECNET 
measurements for game 1 are listed in Appendix A. 



TABLE III. 

GAME 1 THROUGHPUT REQUIREMENTS IN KBPS 



Sampling 

Period 


RSM1 in 
@2:1 


RSM2 in 
@2:1 


CSFout 

@2:1 


CSFout 

@1:1 


1 


9.35 


23.61 


32 . 96 


16.48 


2 


9.38 


23 . 48 


32 .86 


16.43 


3 


9.53 


23.78 


33.31 


16.66 


4 


9 . 56 


23 . 79 


33.35 


16.68 


5 


9.71 


23.89 


33 • 60 


16.80 


6 


9 . 72 


24 . 49 


34.21 


17.10 


7 


9.19 


20.12 


29.31 


14.65 


8-12 no 


data collected 






1 3 


8.45 


22.95 


31.40 


15.70 


1 4 


9.61 


23 . 60 


33.21 


16.60 


1 5 


9 . 62 


23.94 


33 . 56 


16.78 


1 6 


9 . 50 


23 . 68 


33.18 


16.59 


1 7 


9 . 24 


23 • 56 


32 . 80 


16.40 


1 8 


9 . 44 


23 .61 


33.05 


16.52 


1 9 


9 . 66 


23.93 


33 . 59 


16.80 


20 


9.37 


23.54 


32.91 


16.46 


21 


9 . 67 


23 . 54 


33.21 


16.61 


22 


9 • 09 


23 . 22 


32.31 


16.15 
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The throughputs listed in Table III for CSFout 
are also plotted in Figure 14. Plots are shown both 
for the actual 2:1 speed and the normalized 1:1 speed. 
As shown in Figure 14, the maximum throughput 
requirements for game 1 are 34.21 Kbps at 2:1 and 17.10 
Kbps at 1:1. 

These DECNET measurements were only taken 
during a portion of the simulation, and that portion 
was described by NOSC personnel as not including a "hot 
war" situation. During the period measured, there were 
about 160 objects (ships, submarines, and aircraft) 
present--a scenario size described as "slightly smaller 
than average" by NOSC personnel. During these game 1 
measurements, the time interval for every sampling 
period was between 61 and 65 seconds. Thus, these 
measurements represent a very precise view of the CSF 
throughput requirements during the interval measured. 
However, the total period of measurement is also quite 
short, only about 23 minutes out of a simulation 
lasting several hours. For this reason, the data can 
only be considered as one possible set of throughput 
requirements, rather than representing some larger 
general case. 

2 . Game 2 

The IBGTT measurements for "game 2" were taken 
during a simulation conducted at NOSC on November 7, 
1986. Like game 1 , game 2 was conducted using two 
RSMs . The entire game 2 simulation was conducted at a 
2:1 speed. The calculated CSF throughput requirements 
for game 2 are listed in Table IV, using the same 
format as Table III. As before, CSFout is listed both 
for the actual 2:1 speed as well as the normalized 1:1 
speed. The DECNET measurements for game 2 are listed 
in Appendix B. 
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REQUIRED THROUGHPUT 




DATA SAMPLING PERIODS 



Figure 14. CSF Throughput Required to Network Game 1 
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TABLE IV. 

GAME 2 THROUGHPUT REQUIREMENTS IN KBPS 

Sampling RSM1 in RSM2in CSFout CSFout 

Period @ 2:1 @ 2:1 @ 2:1 @ 1:1 


1 


0 . 50 


0.51 


1.01 


0.51 


2 


2 . 68 


2 . 69 


5 . 37 


2 . 69 


3 


6 . 23 


6 . 34 


12.57 


6 .29 


4 


7 . 43 


7 . 84 


15-27 


7 . 64 


5 


8 . 43 


10.76 


19.19 


9 . 60 


6 


9 .51 


14.33 


23.84 


11.92 


7 


10.18 


15.15 


25 . 33 


12.67 


8 


10.62 


16.15 


26 . 77 


13.39 


9 


10.72 


16.21 


26 . 93 


13.47 


1 0 


10.47 


15.91 


26 . 38 


13.19 


1 1 


11.43 


17.04 


28.47 


14.24 


1 2 


11.90 


17.47 


29 . 37 


14.69 


13-20 


pause in the game 






21 


12.11 


17.75 


29 . 86 


14.93 


22 


12.09 


17.99 


30 . 08 


15.04 


23 


12.74 


23 . 08 


35.82 


17.91 


24 


14.56 


28 . 32 


42 .88 


21.44 


25 


14.46 


27 . 79 


42 . 25 


21.13 


26 


15.24 


29.51 


44 . 75 


22 . 38 



The throughputs shown in Table IV for CSFout 
are plotted in Figure 15, both at 2:1 speed and 1 :1 
speed. As shown in the plots, the maximum throughput 
requirements for game 2 are 44.75 Kbps at 2:1 and 22.38 
Kbps at 1:1. 

Unlike game 1 , the DECNET measurements for game 
2 were taken over the entire course of the simulation. 
This is reflected in the plots shown in Figure 15, 
which reveal a steady growth in required throughput as 
the simulation progresses. To make coverage of the 
entire simulation possible, the sample periods were 
increased from 60 seconds to 15 minutes. The number of 
objects in the game varied from 60 at the beginning to 
approximately 300 at the peak of the conflict. This 
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REQUIRED THROUGHPUT 




DATA SAMPLING PERIODS 



Figure 15. CSF Throughput Required to Network Game 2 
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scenario was described, by NOSC personnel as being 
"slightly larger than average." 

While it may appear that the curves in Figure 
15 will continue to increase after the last sample 
period, the simulation actually ended in the period 
following the last one shown. The discontinuity in the 
data is due to the simulation being placed in a "pause" 
for about 1 .5 hours over lunch. Note that even using 
2:1 speed it took an entire working day to complete 
this simulation. 
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VI. ANALYSIS OF NETWORK PERFORMANCE 



A. MODELING THE PROBLEM 

Having obtained, some reasonable values for the 
throughput requirements of the application (IBGTT), it 
is now necessary to determine under what consitions 
DISNET can be expected to support those requirements. 
There are many possible approaches to estimating the 
performance of a packet switched network, but they can 
generally be broken down into three areas: mathematical 
analysis, computer simulation, and direct measurement 
[15], [16]. In this case, direct measurement will not 

be possible until SIMNET is fully implemented. 

Computer simulation and mathematical analysis are 
similar in that both techniques require the network to 
be modeled. In the case of computer simulation, the 
network is modeled in the form of algorithms and data 
structures. In the case of mathematical analysis, the 
network is modeled as a set of equations. Modeling 
typically requires that some aspects of the network be 
greatly simplified in order that the network properties 
of interest may be analyzed. 

In this thesis, expected network throughput will be 
analyzed through the use of a simplified model of a 
switching node (or IMP). This model is adapted from 
one presented by Rubin [17], who uses it to develop 
general expressions for packet waiting time at a 
switching node. The model presented below will be used 
to develop an equation which relates maximum 
application throughput to the amount of internal 
network traffic present at the source node. 
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In fact, the result of this analysis is not 
application throughput through the network--it is 
simply application throughput through the source node. 
However, from the perspective of the application there 
are two bottlenecks on its host-host connection: the 
source node and the destination node. Between these 
two nodes there are multiple pathways available for the 
transfer of application data, making it reasonable to 
assume that the network is capable of handling packets 
at the rate the source node sends them. The effects of 
network traffic at the destination node will not be 
considered at this time, though clearly those 
conditions are important. Thus, by restricting the 
analysis to only the source node it is assumed that the 
rest of the network is capable of handling the 
application traffic at the rate that the source node 
transfers it from the source host. This assumption is 
discussed in detail later in the thesis. 

B. SWITCHING NODE MODEL 

1 . Traffic Through the Node 

The model presented here is a general model for 
any switching node in the network. However, the model 
will primarily be applied as a model of the source node 
for the transmission of IBGTT application data. Thus, 
the terms "source node" and "switching node" are 
synonymous for the purpose of this discussion. 

The traffic arriving at the switching node is 
modeled as consisting of two classes: internal and 

external. The internal traffic consists of the normal 
flow of IMP-IMP packets which are being routed to the 
switching node. The external traffic consists of X.25 
ARPANET messages which are being transmitted from a 
host to the switching node for delivery through the 
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network. The internal and external arrivals combine to 
produce a stream of output traffic from the node. A 
diagram of this switching node model is shown in Figure 
16. In the figure, all internal traffic is shown to be 
on one trunk line while all output traffic is shown to 
be on another. In fact, there can be multiple internal 
arrival channels and multiple output channels without 
affecting any of the following discussion. 

In this model, the internal traffic is 
characterized by a packet arrival rate of "Rj_" and a 
packet length of "L^". The internal traffic will be 
described by using an average packet arrival rate for 
Rj_ . This is because the rate of network traffic over 
any line is very unpredictable at any moment, but it 
can be time averaged to a reasonably consistent value. 
Similarly, an average value will be used for the 
internal packet length, Lj_ . Again, there is a wide 
range of possible packet lengths, but network 
measurements have shown that the average packet length 
for all network traffic is very consistent. 

External arrival traffic is characterized by an 
arrival rate of "R e " and a message length of "L e ". 
Unlike the case for internal traffic, measured averages 
do not have to be used for these values. Since this 
model is only considering IBGTT as a source of external 
traffic, the value of L e is fixed to the maximum 
possible length of an X.25 ARPANET message. Similarly, 
the arrival rate, R e , is fixed at the maximum arrival 
rate possible given the capacity of the host-IMP 
connect i on . 

While the internal packets are considered to be 
unchanged by the switching process at the node, that is 
not true of the external messages. Each ARPANET 
message received at the switching node generates 
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Figure 16. Model of a Switching Node 
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several IMP-IMP packets. These packets are 
characterized by a ratio of "M" packets produced per 
message and a packet length of "Lp". Since the 
arriving external messages are of maximum length, these 
parameters can also be fixed at their maximum value. 

In summary, the following parameters have been 
defined for the switching node model: 



internal packet arrival rate: Rj_ 
average internal packet length: Lj_ 
external message arrival rate: R e 
fixed external message length: L e 
number of IMP-IMP packets 

generated per external message: M 



fixed length of 

externally generated IMP-IMP packets: Lp 

2 . Packet Service at the Node 

Packets arriving at the switching node often 
have to wait for service while previously arriving 
packets are served by the node. Since there can be 
several input channels of arriving packets, each 
channel can be considered to have a waiting queue to 
hold these packets. The switching node is modeled as a 
single-server process. This means that only one packet 
can be served (i.e., transmitted out of the node) at a 
time. Thus, each packet in a waiting queue must wait 
for every previously arriving packet to be served by 
the switching node, one at a time. 
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The time required for the switching node to 
service an individual packet is modeled to be the time 
required to transmit the packet onto the output trunk 
line. This model assumes that processing time in the 
IMP is negligible. Thus, service time is strictly a 
function of packet length and output line capacity. In 
this model, all trunk lines connected to the switching 
node are assumed to have capacity, "C", equal to 50 
Kbps, the most common trunk line capacity in MILNET . 
This 50 Kbps capacity will also be assigned to the 
host-IMP connection. 

From these assumptions, a general expression 
for packet service time, "A", can be defined: 

A = L / C (6.1) 

From equation 6.1 , specific expressions for the service 
time of the different classes of packets can be 
obtained : 



internal : 


o 

•H 

II 

•H 

< 


( 6.2 ) 


externally produced: 




( 6.3 ) 



Since each external message produces M packets of 
length Lp , the service time of an external message can 
be expressed: 

external message: A e = M * Ap ( 6.4 ) 

C. WAITING TIME ANALYSIS 

1 . Packet Interarrival Time 

The parameter "t n " is defined as the time of 
arrival for packet number "n" of arbitrary traffic 
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class. More specifically, the arrival times for each 
class of packets is defined: 

internal packet arrival time: t n 1 

external message arrival time: t n e 



Using this notation, a general expression for packet 
interarrival time can be defined as follows: 



^n+1 _ ^n+1 ^n 



( 6.5 ) 



Here, T n+ -| is the time interval between the arrival of 
packet "n" and the arrival of packet "n+1 " . The 
specific equations for the different classes of traffic 
follow directly: 



internal : 



external : 



Tn+1 1 = tn+1 1 - tn 1 



H e — .4- e + e 

1 n+1 ~ x n+1 x n 



( 6.6 ) 
( 6.7 ) 



2 . Batch Arrival Model 

The number of internal packets which arrive 
during the external message interarrival time, T n+ i e , 
is defined as "N j_ ( T n+1 e ) " . While the actual number for 
any given interarrival time will vary with the dynamics 
of network loading and routing, time averaging can be 
used to approximate this number, as follows: 



internal : 



(avg) H 1 (T n+1 e) = Ri * T n+1 ® 



( 6.8 ) 



the number of external messages which arrive 
internal packet interarrival time is defined 



Similarly , 
during the 
as follows 
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